[core] Fix schema evolution for multiset elements - #9545

[P1] Support reading existing multiset data after committing the schema change

This change lets SchemaManager commit a multiset element-type evolution, but the read-side schema-evolution path still has no MultisetType support. SchemaEvolutionUtil.createCastExecutor handles RowType, ArrayType, and MapType; a multiset change falls through to CastExecutors.resolve, which returns null for multiset-to-multiset casts.

I reproduced this on the current PR head with the following sequence:

1. Create a table containing MULTISET<INT>.
2. Write a row under that schema.
3. Alter the element type to BIGINT.
4. Read the existing row.

The ALTER succeeds, but the read fails with:

NullPointerException: Cannot cast from type MULTISET<INT> to type MULTISET<BIGINT>
    at SchemaEvolutionUtil.createCastExecutor(SchemaEvolutionUtil.java:262)

The same missing read path also affects nested row evolution inside a multiset, such as adding a field or widening an existing field, whenever files written with the old schema are present.

Please add a MultisetType branch to the read-side evolution logic. Since a multiset is represented as an InternalMap, it should recursively cast the key array (the elements) while preserving the integer multiplicity value array. An end-to-end regression test should write data before the schema change and read it afterward; the current tests only verify the resulting metadata.

Requirement fit: SUPPORTED. Implementation: FINDINGS.

The earlier missing read-side multiset cast is fixed: the new write-before-ALTER/read-afterward regression passes for INT to BIGINT and nested row widening/addition. There is still a multiplicity-loss case when an accepted element evolution maps distinct old elements to equal new elements; details are inline.

Validation: 60 SchemaManager/table tests passed after compiling this PR's core sources and matching RESTApi, avoiding the newer cached SchemaManager-interface ABI. An additional real stored-table probe checked three cases: INT to BIGINT preserved total multiplicity 5; INT to FLOAT with colliding values, and dropping a distinguishing field from a multiset's row element, both produced duplicate keys and total multiplicity 3 after the standard row-value copy. This was a local core read/copy reproduction, not a Flink or Spark SQL run.